test(android-e2e): record rotation state and logcat rotation decisions on a failed step - #2350
Open
thymikee wants to merge 4 commits into
Open
test(android-e2e): record rotation state and logcat rotation decisions on a failed step#2350thymikee wants to merge 4 commits into
thymikee wants to merge 4 commits into
Conversation
…s on a failed step The Android smoke has failed on the post-alert canary since 2026-09-03, and the failed-step screenshot from run 34021894996 shows why the reads miss: the device is in landscape at that point, with the canary below the fold, although `orientation portrait` had taken effect (the fixture confirmed it and every tap before the alert landed at x=540). Nothing we keep says what rotated it. A failed step now also writes failed-step-N-device.txt with the two rotation settings, the display's rotation lines, and WindowManager's rotation decisions from logcat, read through adb so they stand even when the CLI path failed.
…ons and display rotation fields
Size Report
Startup median (7 runs, lower is better):
|
Member
Author
|
The diagnostics are useful, but 825faf0 needs a small follow-up before merge:
|
Member
Author
|
The iOS smoke lane also finished red at the depth-1 bridge assertion, after target-resolution-failed fell back to XCTest. This is outside the Android diagnostics diff; the existing collector/test findings remain, and the required lane still needs to pass. |
…e probes, test it Review follow-up on the rotation evidence. The collectors move out of the harness closure into failed-step-evidence.ts (fallow complexity), where the platform hook runs alongside the screenshot and snapshot and is bounded as a group (15s) so it can never delay them; a hook that throws, answers nothing, or never answers records nothing for the device file and leaves the CLI evidence in place. The Android probes get a 5s per-command bound, and logcat lines are capped in count and length. Deterministic tests cover the file contents, the hook failure and timeout cases, and the harness naming every evidence file, device file included, in failed-step.txt.
Member
Author
|
Addressed:
Main merged in for the typecheck break that failed the iOS lane's build step here. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Diagnostics for the Android Smoke failures on the post-alert canary (
get text id="automation-alert-result"since 2026-09-03,wait for Alert result: cancelledon #2344).The failed-step screenshot and snapshot from https://github.com/callstack/agent-device/actions/runs/34021894996 show the device in landscape at the timeout:
Open automation alertis 2220px wide and the alert-result canary sits below the fold, so 16 readable polls never contained it. Every tap before the alert landed at x=540, so the device was portrait throughopen alert;orientation portraithad been confirmed by the fixture 12s earlier. The same layout explains the earlierSelector did not matchfailures on that step. Nothing in the artifacts says what rotated it: the emulator's Vulkan surface events happen ~95s after boot in passing runs too, and the guest settings alone never flip a local emulator.Change
A failed step now also writes
failed-step-N-device.txtnext to the screenshot and snapshot, through adb rather than agent-device so it stands even when the CLI path is what failed:settings get system accelerometer_rotationanduser_rotation(the two valuesorientationwrites)dumpsys displaylogcat -d, with the reason Android logs for eachThe shared harness gains an optional
deviceEvidencehook; iOS does not implement it yet.Validation
Probe commands verified against a local emulator (settings, display rotation lines, logcat rotation decisions all return output). Root typecheck, oxlint, oxfmt clean. The evidence itself only appears on a failed CI step, which the Android lane has been producing on roughly half its runs.